Introducción a la Ingeniería de Software (Presentación Powerpoint) (página 2)

Partes: 1, 2

11
MODELO EN V AMPLIADO

12
MODELO EN V
Incluye fases similares a las del modelo en cascada pero de forma jerárquica. En horizontal se representa el avance en el desarrollo y en vertical el nivel de detalle.
VERIFICACIÓN, comprobación de que una parte del sistema cumple con sus especificaciones.
VALIDACIÓN, comprobación de que un elmento satisface las necesidades del usuario identificadas durante el análisis.

13
PROTOTIPOS
En los modelos clásicos se insiste en las actividades de revisión de resultados al final de cada fase para evitar la vuelta atrás, que no se contempla de una forma organizada y resulta muy costosa. Están orientados a una forma de desarrollo lineal.
PROTOTIPO, es un sistema auxiliar que permite probar experimentalmente soluciones parciales a los requisitos del sistema
Para que el coste de desarrollo del prototipo sea bajo en relación al del sistema final podemos:
Limitar las funciones
Limitar su capacidad
Limitar su eficiencia
Evitar limitaciones de diseño, utilizando un hardware más potente que el que ejecutará el sistema final
Reducir la parte a desarrollar

14
PROTOTIPOS RÁPIDOS
Su finalidad es solo adquirir experiencia, no se aprovechan como producto (usar y tirar). Se denominan maquetas cuando su funcionalidad o capacidad es muy limitada.
El sistema final se codifica totalmente partiendo de cero, no se aprovecha el código del prototipo
Lo importante de estos prototipos es que se desarrollen en poco tiempo.

15
PROTOTIPOS RÁPIDOS

16
PROTOTIPOS EVOLUTIVOS
En este caso se intenta aprovechar al máximo el código del prototipo, y para ello se emplea el mismo hardware/software del sistema final.
Se realizan fases de análisis y diseño parcial, que se van ampliando hasta construir el sistema final mediante adiciones sucesivas.
Se puede considerar un modelo en cascada en bucle, de manera que en cada iteración se va avanzando en el desarrollo.
HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS, se emplean lenguajes de 4ª generación, que son de alto nivel y de tipo declarativo. También se emplean lenguajes de especificación, como VDM y Z. Si disponemos del compilador correspondiente podemos obtener automáticamente el código del prototipo.
En el desarrollo de prototipos es clave la reutilización de software.

17
PROTOTIPOS EVOLUTIVOS

18
MODELO EN ESPIRAL
Puede considerarse como un refinamiento del modelo evolutivo general que introduce el análisis de riesgo como elemento fundamental para guiar la evolución del proceso de desarrollo.
En la dimensión radial se representa el esfuerzo realizado en el desarrollo (siempre creciente)
En cada iteración 4 fases:
PLANIFICACIÓN, determina que parte del desarrollo se abordará en ese ciclo.
ANALISIS DE RIESGO, evaluar diferentes alternativas para esa parte del desarrollo seleccionando la más ventajosa y tomando precauciones para evitar los posibles inconvenientes.
INGENIERÍA, las actividades de los modelos clásicos
EVALUACIÓN, se analizan los resultados de la fase de ingeniería.

19
MODELO EN ESPIRAL

20
MANTENIMIENTO DEL SOFTWARE
El mantenimiento no representa una actividad específica, sino que consiste en rehacer parte de las actividades correspondientes a las otras fases del desarrollo para introducir cambios sobre una aplicación ya en fase de explotación.
MANTENIMIENTO CORRECTIVO, su finalidad es corregir errores que no fueron detectados en el desarrollo del producto.
MANTENIMIENTO ADAPTATIVO, modificar una aplicación para adaptarla a las nuevas necesidades del entorno.
MANTENIMIENTO PERFECTIVO, se trata de ir obteniendo versiones mejoradas del producto

21
GESTIÓN DE CAMBIOS
El mantenimiento supone la realización de una serie de cambios sucesivos
Si afectan a la mayor parte del sistema se puede plantear como un nuevo desarrollo.
Cada cambio debe ser documentado con:
INFORME DEL PROBLEMA, que ocasiona el cambio. Suele ser propuesto por el cliente.
INFORME DE CAMBIO, describe la solución dada al problema y el cambio realizado
REINGENIERÍA, es necesaria cuando el desarrollo de una aplicación no está documentado y se dispone solamente del código. Se llama también ingeniería inversa porque supone reconstruir y documentar las fases de análisis y diseño llegando a la estructura modular de la aplicación y las dependencias entre módulos y funciones. Estas actividades organizan y documentan un sistema deficiente.

22
GARANTÍA DE CALIDAD
Para evaluar la calidad son necesarias técnicas de aplicación de métricas precisas tanto sobre los productos software como a sus procesos de desarrollo.
McCall propone un esquema basado en valoraciones a 3 niveles:
FACTORES, valoración significativa de la calidad en base a los criterios establecidos
CRITERIOS, aspectos de nivel intermedio que influyen en los factores de calidad
MÉTRICAS, mediciones puntuales de determinadas características del producto.
Entre los factores de calidad tenemos:
CORRECCIÓN, grado en que cumple con las especificaciones
FIABILIDAD, grado de ausencia de fallos
EFICIENCIA, reilación entre la cantidad de resultados y los recursos requeridos
SEGURIDAD, dificultad para el acceso a datos por personas no autorizadas
FACILIDAD DE USO, esfuerzo requerido para el aprendizaje de la aplicación
MANTENIBILIDAD. Facilidad para corregir el producto en caso necesario.
FLEXIBILIDAD, facilidad para modificar el producto
FACILIDAD DE PRUEBA, depende del esfuerzo requerido para comprobar su corrección o fiabilidad
TRANSPORTABILIDAD, facilidad para adaptar el producto a otra plataforma
REUSABILIDAD, facilidad para usar partes del producto en otros desarrollos
INTEROPERATIVIDAD, facilidad del producto para trabajar con otros

23
PLAN DE GARANTÍA DE CALIDAD (SQAP)
Es un documento formal para organizar el proceso de desarrollo software de manera que se asegure la calidad del producto final. Debe contemplar:
Organización, dirección y seguimiento de los equipos de desarrollo
Modelo de ciclo de vida a seguir, detallando fases y actividades
Documentación requerida, determinando contenido y guión de cada documento
Revisiones y auditorias, para garantizar que las actividades y los documentos son correctos
Organización de las pruebas, a distintos niveles
Organización de la etapa de mantenimiento, determinando cómo gestionar la realización de cambios

24
REVISIONES
Consiste en inspeccionar el resultado de una actividad para determinar si es aceptable o contiene defectos que han de ser subsanados.
Las revisiones deben ser formalizadas y contempladas en el modelo de ciclo de vida:
Deben ser realizadas por un grupo de personas y no individualmente
El grupo de be ser reducido
Debe ser imparcial, nada que ver con los desarrolladores
Se debe revisar el producto, pero no el productor ni el proceso de producción
Se debe establecer de antemano una lista formal de comprobaciones
Se debe levantar acta de la reunión de revisión, recogiendo las decisiones tomadas

25
PRUEBAS
Consiste en hacer funcionar el producto o una parte de él y comprobar si los resultados son correctos.
No permite garantizar la calidad del producto. En general no es posible probar un producto de forma exhaustiva, debido a su complejidad.

26
GESTIÓN DE CONFIGURACIÓN
CONFIGURACIÓN, disposición de las partes que componen una cosa y le dan su peculiar figura.
La CONFIGURACÏÓN SOFTWARE se refiere a la manera en que diversos elementos se combinan para construir un producto software.
Se han de combinar todos los elementos que intervienen en el desarrollo:
Documentos del desarrollo
Código fuente
Programas, datos y resultado de las pruebas
Manuales de usuario
Documentos de mantenimiento, informes de problemas y cambios
Prototipos intermedios
Normas particulares del proyecto
Dado que los elementos software van evolucionando a lo largo del desarrollo se requiere:
Control de versiones, almacenar de forma organizada las sucesivas versiones de cada elemento de la configuración.
Control de cambios, garantizar que las diferentes configuraciones del software se componen de elementos compatibles entre sí (línea base).

27
NORMAS Y ESTÁNDARES
IEEE, Institute of Electrical and Electronics Engineer de USA [IEEE93]
DoD, Departament od Defense de USA [DoD88]
ESA, Agencia Europea del Espacio [ESA91]
ISO, organismo internacional de normalización (International Standars Organization). En España AENOR.
METRICA-2, desarrollada por el Consejo Superior de Informática del MAP. Se basa en la metodología de análisis y diseño de Yourdon/DeMarco.